home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1553.txt < prev    next >
Text File  |  1994-08-01  |  47KB  |  1,292 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          S. Mathur
  8. Request for Comments: 1553                                      M. Lewis
  9. Category: Standards Track                            Telebit Corporation
  10.                                                            December 1993
  11.  
  12.  
  13.              Compressing IPX Headers Over WAN Media (CIPX)
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state and
  22.    status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    This document describes a method for compressing the headers of IPX
  27.    datagrams (CIPX).  With this method, it is possible to
  28.    significantly improve performance over lower speed wide area
  29.    network (WAN) media.  For normal IPX packet traffic, CIPX can
  30.    provide a compression ratio of approximately 2:1 including both IPX
  31.    header and data.  This method can be used on various type of WAN
  32.    media, including those supporting PPP and X.25.
  33.  
  34.    This memo ia a product of the Point-to-Point Protocol Extensions
  35.    (PPPEXT) Working Group of the IETF.  Comments should be sent to
  36.    the authors and the ietf-ppp@ucdavis.edu mailing list.
  37.  
  38. Specification of Requirements
  39.  
  40.    In this document, several words are used to signify the requirements
  41.    of the specification.  These words are often capitalized.
  42.  
  43.     MUST
  44.  
  45.       This word, or the adjective "required", means that the
  46.       definition is an absolute requirement of the specification.
  47.  
  48.     MUST NOT
  49.  
  50.       This phrase means that the definition is an absolute
  51.       prohibition of the specification.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Mathur & Lewis                                                  [Page 1]
  59.  
  60. RFC 1553                         CIPX                      December 1993
  61.  
  62.  
  63.     SHOULD
  64.  
  65.       This word, or the adjective "recommended", means that there
  66.       may exist valid reasons in particular circumstances to
  67.       ignore this item, but the full implications should be
  68.       understood and carefully weighed before choosing a
  69.       different course.
  70.  
  71.     MAY
  72.  
  73.       This word, or the adjective "optional", means that this
  74.       item is one of an allowed set of alternatives.  An
  75.       implementation which does not include this option MUST be
  76.       prepared to interoperate with another implementation which
  77.       does include the option.
  78.  
  79. Introduction
  80.  
  81.    Internetwork Packet Exchange (IPX) is a protocol defined by the
  82.    Novell Corporation [1].  It is derived from the Internet Datagram
  83.    Protocol (IDP) protocol of the Xerox Network Systems (XNS) family
  84.    of protocols.  IPX is a datagram, connectionless protocol that does
  85.    not require an acknowledgment for each packet sent.  The IPX
  86.    protocol corresponds to the network layer of the ISO model.
  87.  
  88.    Usually, there is a transport layer protocol above IPX.  The most
  89.    common transport protocol is the Netware Core Protocol (NCP), which
  90.    is used for file server access.  The Sequenced Packet Exchange
  91.    (SPX) is the reliable connection-based transport protocol commonly
  92.    used by applications.
  93.  
  94.    The IPX packet consists of a 30 octet IPX header, usually followed
  95.    by the transport layer protocol header.  The NCP header is 6 octets
  96.    in length.  The SPX header is 12 octets in length.
  97.  
  98.    Two strategies are described below for compressing IPX headers.
  99.    This specification requires that implementations of CIPX support
  100.    both IPX header compression strategies.  These header compression
  101.    algorithms are based on those Van Jacobson described [2] for TCP/IP
  102.    packets.
  103.    The first strategy is to compress only the IPX header.  This
  104.    compression algorithm can be used to compress any IPX packet,
  105.    without affecting the transport protocol.  This algorithm
  106.    compresses a 30 octet IPX header into a one to seven octet header.
  107.  
  108.    The second strategy is to compress the combined IPX and NCP
  109.    headers.  This algorithm compresses only NCP packets with NCP type
  110.    of 0x2222 and 0x3333.  This algorithm compresses a 36 octet NCP/IPX
  111.  
  112.  
  113.  
  114. Mathur & Lewis                                                  [Page 2]
  115.  
  116. RFC 1553                         CIPX                      December 1993
  117.  
  118.  
  119.    header into a one to eight octet header.
  120.  
  121.    Lastly, it is possible and many times desirable, to use this type
  122.    of header compression in conjunction with some type of data
  123.    compression.
  124.  
  125.    Data compression technology takes many forms. Link bit stream
  126.    compression is a common approach over very low speed asynchronous
  127.    links, normally performed by modems transparently.  Transparent bit
  128.    stream compression is also offered in some DSUs, routers and
  129.    bridges.  Data compression can be provided using protocols such as
  130.    CCITT V.42bis[3], MNP 5, Lempel-Ziv, or LAPB[4].
  131.  
  132.    When using both header and data compression, the sequence of
  133.    compression is important.  When sending packets, data compression
  134.    MUST be done after header compression.  Conversely when receiving
  135.    packets, data decompression MUST be done before header
  136.    decompression.
  137.  
  138. IPX Compression Algorithm
  139.  
  140.    The normal IPX header consists of the following fields: checksum,
  141.    packet length, transport control (hop count), packet type,
  142.    destination and source address fields.
  143.  
  144.                              +-----------------------+
  145.                              |       Checksum        |
  146.                              +-----------------------+
  147.                              |     Packet Length     |
  148.                              +-----------+-----------+
  149.                              |    Hops   |Packet Type|
  150.                              +-----------+-----------+
  151.                              |      Destination      |
  152.                              |        Address        |
  153.                              |      (12 Octets)      |
  154.                              +-----------------------+
  155.                              |        Source         |
  156.                              |        Address        |
  157.                              |      (12 Octets)      |
  158.                              +-----------------------+
  159.  
  160.                                  IPX PACKET HEADER
  161.  
  162.    The IPX header diagram above is shown without the field alignment
  163.    details.  Consider each field of the IPX header separately, and how
  164.    it typically changes.
  165.  
  166.    Historically, Novell has not used the Checksum field in the IPX
  167.  
  168.  
  169.  
  170. Mathur & Lewis                                                  [Page 3]
  171.  
  172. RFC 1553                         CIPX                      December 1993
  173.  
  174.  
  175.    header, and has required that this field be set to 0xFFFF.  Since the
  176.    Checksum field remains constant, it is clear that the value can be
  177.    compressed.
  178.  
  179.    Where Checksums are implemented (not 0xFFFF), the Checksum MUST be
  180.    included in the compressed packet.  Recalculating the checksum would
  181.    destroy the end-to-end reliability of the connection.  Note that
  182.    Checksums are now implemented in the Fault Tolerant Servers.
  183.  
  184.    For most links, the Packet Length can be determined from the MAC
  185.    layer.  There are cases in which the length cannot be determined from
  186.    the MAC layer.  For example, some hardware devices pad packets to a
  187.    required minimum length.  For links where it is not possible to
  188.    determine the IPX packet length from the MAC layer, packet length
  189.    needs to be included in the compressed packet.
  190.  
  191.    The Transport Control (Hops) field usually does not change between
  192.    two end-points.  For the purposes of compression, we will assume that
  193.    it never changes, and will not examine this field when determining a
  194.    connection.
  195.  
  196.    The Packet Type field is constant for any connection.
  197.  
  198.    The Destination and Source Address fields are each made up of 12
  199.    octets: Network (4 octets), Node (6 octets), and Socket (2 octets)
  200.    fields.  An IPX connection is the logical association between two
  201.    endpoints known by a given source and destination address pair.  For
  202.    any specific IPX connection, the Destination and Source Address
  203.    fields are constant.
  204.  
  205.    Hence, the fields that may need to be included in the compressed IPX
  206.    header are the Checksum and the Packet Length.
  207.  
  208.    While using this IPX header compression algorithm, packets can be
  209.    lost.  The loss of an Initial packet presents a problem.  In this
  210.    case, if the sender later tries to send a compressed packet, the
  211.    receiving end cannot decompress the packet correctly.
  212.  
  213.    Sufficient information is not available in the IPX header to
  214.    determine when a re-transmission has occured.  For this reason, it is
  215.    necessary that the sender of an Initial packet be guaranteed that the
  216.    packet has been received.  Therefore, we provide a mechanism for
  217.    Confirmation of an Initial packet.
  218.  
  219. NCP/IPX Header Compression
  220.  
  221.    Since most IPX packets are Netware Core Protocol packets (packet type
  222.    17), compressing the NCP header will give us added performance.  A
  223.  
  224.  
  225.  
  226. Mathur & Lewis                                                  [Page 4]
  227.  
  228. RFC 1553                         CIPX                      December 1993
  229.  
  230.  
  231.    minimal CIPX implementation MUST also implement NCP/IPX compression.
  232.  
  233.                                   +------------+
  234.                                   |    NCP     |
  235.                                   |    Type    |
  236.                                   +------------+
  237.                                   |  Sequence  |
  238.                                   |   Number   |
  239.                                   +------------+
  240.                                   | Connection |
  241.                                   |(low octet) |
  242.                                   +------------+
  243.                                   |   Task     |
  244.                                   |   Number   |
  245.                                   +------------+
  246.                                   | Connection |
  247.                                   |(high octet)|
  248.                                   +------------+
  249.  
  250.                                     NCP HEADER
  251.  
  252.    The NCP header is 6 octets in length consisting of the following
  253.    fields: NCP type, sequence number, connection number and task number.
  254.  
  255.    The NCP type field values that are currently defined are:
  256.  
  257.              1111   Create Connection
  258.              2222   NCP request from workstation
  259.              3333   NCP reply from file server
  260.              5555   Destroy Connection
  261.              7777   Burst Mode Packet
  262.              9999   Server Busy Packet
  263.  
  264.    This NCP header compression algorithm only compresses packets that
  265.    have a type field value of 0x2222 or 0x3333.  If the NCP type is
  266.    0x2222, this packet is a request from the client to the server.
  267.    Conversely if the NCP type is 0x3333, this is a response from the
  268.    server to the client.  All other types of NCP packets are not
  269.    compressed at the NCP level, but are compressed at the IPX level.
  270.    The Create Connection (0x111), Destroy Connection (0x5555) and Server
  271.    Busy (0x9999) packets are not exchanged frequently enough to justify
  272.    special NCP compression.  The Burst Mode (0x7777) packet is discussed
  273.    below.
  274.  
  275.    The connection number is a constant for a given connection.
  276.  
  277.    The sequence number is increased by one for each new request.  Hence
  278.    the sequence number can be determined implicitly.  The decompressor
  279.  
  280.  
  281.  
  282. Mathur & Lewis                                                  [Page 5]
  283.  
  284. RFC 1553                         CIPX                      December 1993
  285.  
  286.  
  287.    increments the sequence number for each compressed packet it receives
  288.    for a connection.
  289.  
  290.    The task number can change unpredictably, although it might remain
  291.    constant for several packets.  If the NCP task number is different
  292.    from the last one for this connection, the NCP task number must be
  293.    included.
  294.  
  295.    If the NCP packet is lost, it will be retransmitted through the
  296.    normal transport layer mechanisms.  The Initial NCP packet does not
  297.    require confirmation, as a re-transmitted packet can be easily
  298.    identified.  This is accomplished by comparing the sequence number of
  299.    the packet to the sequence number of the previous packet.  If the
  300.    sequence number is not exactly one greater than the previous packet,
  301.    a new Initial packet must be sent, although the same connection slot
  302.    may be used.
  303.  
  304.    In the event of compressed packet loss, the sequence number will be
  305.    too small.  When the IPX Checksum is present, the loss can be
  306.    determined at the destination system by an incorrect checksum.  When
  307.    there is no checksum present, the loss is more likely to be detected
  308.    upon receiving a later retransmission.
  309.  
  310. NCP Burst Mode Packets
  311.  
  312.    The burst mode protocol uses the NCP type value of 0x7777.  This type
  313.    of packet does not have the normal NCP header described above.
  314.    Instead, it has a 36 octet burst header.  The above NCP header
  315.    compression algorithm should not be used to compress this packet.
  316.    The IPX header in this packet is still compressible with the IPX
  317.    header compression algorithm described.
  318.  
  319. SPX Packets
  320.  
  321.       SPX packets are typically used by applications which require
  322.       reliable service such as print servers.  It is possible to apply a
  323.       similar NCP/IPX technique to SPX/IPX packets.  At this time, we
  324.       have not described such a mechanism.  The IPX header in this
  325.       packet is still compressible with the IPX header compression
  326.       algorithm described.
  327.  
  328. Compression Header
  329.  
  330.       IPX compression should be negotiated by some means (eg. IPXCP or
  331.       IPXWAN).  Each end must negotiate the desired options, such as the
  332.       maximum number of concurrent connections which will be maintained
  333.       in each direction.  Once IPX compression is negotiated, all IPX
  334.       packets sent over that link have a CIPX header added to the
  335.  
  336.  
  337.  
  338. Mathur & Lewis                                                  [Page 6]
  339.  
  340. RFC 1553                         CIPX                      December 1993
  341.  
  342.  
  343.       beginning of the packet.  The CIPX header is variable in length.
  344.  
  345.       The one octet CIPX header is added even when a regular IPX packet
  346.       is sent over the link.  By including the CIPX header on every
  347.       packet, we support the ability to run CIPX over various WAN links
  348.       as if it were a normal IPX packet.  It does not rely on any new
  349.       link specific packet demultiplexing.
  350.  
  351.       Implementations of this compression protocol must maintain send
  352.       and receive tables indicating the state of each connection.  The
  353.       original header for each connection is stored in a "slot".
  354.       Typically, each client-server connection will use a separate slot.
  355.       Both sides keep a copy of the full IPX header corresponding to
  356.       each slot.  The sending side (compressor) uses this information to
  357.       determine the fields that have changed.  The receiving side
  358.       (decompressor) uses this information to reconstruct the original
  359.       packet header.
  360.  
  361.       The CIPX packet header specifies the type of the packet and any
  362.       options for that packet.  The minimum CIPX header is one octet in
  363.       length.
  364.  
  365.          7   6   5   4   3   2   1   0
  366.        +---+---+---+---+---+---+---+---+
  367.        |   |   |   |   |   |   |   |   |
  368.        +---+---+---+---+---+---+---+---+
  369.          ^   ^   ^   ^   ^   ^   ^   ^
  370.          |   |   |   |   |   |   |   |
  371.          |   |   |   |   |___|___|___|___ Packet Type
  372.          |   |   |   |                    0    Compressed
  373.          |   |   |   |                    1    Regular
  374.          |   |   |   |                    3    Confirmed Initial
  375.          |   |   |   |                    5    Confirm
  376.          |   |   |   |                    7    Unconfirmed Initial
  377.          |   |   |   |                    9    Reject
  378.          |   |   |   |                   11-15 Reserved
  379.          |   |   |   |
  380.          |__ |__ |__ |___________________ Packet Type Dependent Flags
  381.  
  382.                                 FLAGS OCTET
  383.  
  384.       As can be seen above, the low order bits specify the packet type.
  385.       All Compressed packets have a lowest bit of zero.  The other
  386.       packet types are odd numbers.
  387.  
  388.       Note that the Flags octet MUST NOT contain the value 0xFF.  This
  389.       is necessary to distinguish the CIPX flags octet from a normal IPX
  390.       header with a 0xFFFF checksum field.  It is important to be able
  391.  
  392.  
  393.  
  394. Mathur & Lewis                                                  [Page 7]
  395.  
  396. RFC 1553                         CIPX                      December 1993
  397.  
  398.  
  399.       to recognize a normal IPX header regardless of the state of
  400.       compression.  It is possible with some link layer protocols such
  401.       as X.25 Permanent Virtual Circuits that one end of the link may
  402.       fail and start sending regular IPX packets without the CIPX
  403.       header.  CIPX implementations MUST recognize this situation and
  404.       renegotiate the use of CIPX.
  405.  
  406.       Each packet type has associated flag bits, which are called Packet
  407.       Type Dependent Flags.  Different packet types have different
  408.       Packet Type Dependent Flags.  All bits that are reserved or are
  409.       not specified must be set to zero.
  410.  
  411.       Since none of the packet types other than Compressed currently
  412.       uses any of the flag bits, the packet type field could easily be
  413.       expanded.  Any future expansion must ensure that at least one of
  414.       the bits in the Flags octet remains zero so the value cannot be
  415.       0xFF.
  416.  
  417. Compressed Packet
  418.  
  419.    This type of packet does not contain a packet header (either 30 byte
  420.    IPX, or 36 byte NCP).  A slot number indicates to the receiver which
  421.    saved header to use to formulate the original packet header before
  422.    passing the packet up to IPX.
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Mathur & Lewis                                                  [Page 8]
  451.  
  452. RFC 1553                         CIPX                      December 1993
  453.  
  454.  
  455.       ________________________________ Slot Number
  456.       |                                0    Assume same as last packet
  457.       |                                1    Included in packet
  458.       |
  459.       |   ____________________________ Checksum
  460.       |   |                            0    Assume 0xFFFF
  461.       |   |                            1    Included in packet
  462.       |   |
  463.       |   |   ________________________ Length
  464.       |   |   |                        0    Determine from MAC length
  465.       |   |   |                        1    Included in packet
  466.       |   |   |
  467.       |   |   |   ____________________ Task Number (NCP only)
  468.       |   |   |   |                    0    Assume same as last packet
  469.       |   |   |   |                    1    Included in packet
  470.       |   |   |   |
  471.       |   |   |   |   ________________ Reserved (Must be zero)
  472.       |   |   |   |   |   |   |
  473.       |   |   |   |   |   |   |   ____ Packet Type
  474.       |   |   |   |   |   |   |   |    0    Compressed Packet
  475.       v   v   v   v   v   v   v   v
  476.     +---+---+---+---+---+---+---+---+
  477.     |   |   |   |   | 0 | 0 | 0 | 0 |
  478.     +---+---+---+---+---+---+---+---+
  479.       7   6   5   4   3   2   1   0
  480.  
  481.    Consider each flag in the flags octet, looking at the high order bits
  482.    working toward the lower order bits.  Each of the fields is optional,
  483.    but if present will be found in the same order in the compressed
  484.    packet header.
  485.  
  486. Slot Number
  487.  
  488.    The slot number flag indicates the slot number field is included in
  489.    the compressed packet.  The slot number field is one octet in length
  490.    and specifies the number of the slot which corresponds to the Initial
  491.    packet header.  Slots are numbered starting at zero and continue to
  492.    the maximum number of slots minus one.
  493.  
  494.    By default, slot compression is disabled.  If negotiated, slot
  495.    compression can be enabled for those slots which were created by the
  496.    Unconfirmed Initial packet.  When set to one (1), the slot number
  497.    flag indicates the inclusion of the the slot number in the compressed
  498.    packet.  When set to zero (0), the slot number flag indicates the
  499.    omission of the the slot number and specifies the use of the same
  500.    slot number as for the last packet.
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Mathur & Lewis                                                  [Page 9]
  507.  
  508. RFC 1553                         CIPX                      December 1993
  509.  
  510.  
  511.       Implementation Note:
  512.  
  513.          Slot compression MUST only be enabled in a receiver which can
  514.          account for all erroneous and discarded packets.  When a packet
  515.          has been discarded, the slot number is indeterminate for future
  516.          packets.  The decompressor MUST discard all further packets
  517.          until a slot number is received.
  518.  
  519. Checksum
  520.  
  521.    When set to one (1), the checksum flag indicates the compressed
  522.    packet will include the 2 octet checksum.  When set to zero (0),
  523.    this flag indicates the omission of the checksum and the decompressor
  524.    is to assume the checksum is 0xFFFF.  Note that meaningful checksums
  525.    must be included in the packet with the checksum flag set to one (1).
  526.  
  527. Length
  528.  
  529.    When set to one (1), the length flag indicates the inclusion of the
  530.    IPX data length field in the compressed packet.  When set to zero
  531.    (0), the length flag indicates the omission of the IPX data length
  532.    field in the compressed packet.
  533.  
  534.    This is the Length field from the original IPX packet header.  It
  535.    specifies the length of IPX header and data in the packet prior to
  536.    compression.  It does not include the CIPX compression field such as
  537.    flags, slot number, checksum, length field, or the NCP task number.
  538.    Note that it is preferable to determine the length field from the MAC
  539.    layer whenever possible, by subtracting the length of the compression
  540.    header fields and adding the length of the saved packet header.
  541.  
  542.    Since every octet is significant over lower speed WAN links, an
  543.    optimization is used in the specification of the length.  It can be
  544.    specified as a one, two or three octet field.  If the length is in
  545.    the range 0 to 127, then it is specified as a one octet field.  If
  546.    the length is in the range 128 to 16383, it is specified as a two
  547.    octet field in high to low order, with the first octet in the range
  548.    128 to 191.  Otherwise, if the length is greater than 16383, the
  549.    first octet contains 192, and the second and third octets contain the
  550.    full length.  (This scheme is extensible to 8 octets, but currently
  551.    is not required in the IPX protocol suite.)
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Mathur & Lewis                                                 [Page 10]
  563.  
  564. RFC 1553                         CIPX                      December 1993
  565.  
  566.  
  567.    +-+-+-+-+-+-+-+-+
  568.    |0|   length    |   length < 128
  569.    +-+-+-+-+-+-+-+-+
  570.  
  571.    ONE OCTET LENGTH FIELD
  572.  
  573.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  574.    |1 0|          length           |   length < 16384
  575.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  576.  
  577.    TWO OCTET LENGTH FIELD
  578.  
  579.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  580.    |1 1 0 0 0 0 0 0|            length             |  length < 65535
  581.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  582.  
  583.    THREE OCTET LENGTH FIELD
  584.  
  585.  
  586. Task Number
  587.  
  588.    When set to one (1), the NCP task number flag indicates the NCP task
  589.    number is included in the compressed packet (see NCP/IPX compression
  590.    above).  When set to zero (0), the NCP task number flag indicates the
  591.    omission of the NCP task number in the compressed packet.  When the
  592.    NCP task number is not included in the compressed packet, we use the
  593.    same NCP task number as that of last packet.
  594.  
  595.    Based upon the bits set in the flags octet, optional portions are
  596.    included in the compressed IPX header.  The minimum compressed IPX
  597.    header contains only the Flags octet.  All fields in the original IPX
  598.    header have been compressed out of the header.  The maximum
  599.    compressed IPX header can include up to 7 octets, the Flags, Slot,
  600.    Checksum (2 octets), and Length (3 octets) fields, or 8 octets if the
  601.    NCP Task Number is included.  The minimum and maximum compressed IPX
  602.    packets are shown below.  Header fields are one octet in length
  603.    except where noted.
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Mathur & Lewis                                                 [Page 11]
  619.  
  620. RFC 1553                         CIPX                      December 1993
  621.  
  622.  
  623.         +--------+---------
  624.         | Flags  | DATA ...
  625.         |  0x00  |
  626.         +--------+---------
  627.  
  628.         MINIMUM COMPRESSED IPX PACKET
  629.  
  630.         +--------+--------+---------+---------+---------
  631.         | Flags  |  Slot  |Checksum | Length  | DATA ...
  632.         |  0xE0  | Number |2 octets |3 octets |
  633.         +--------+--------+---------+---------+---------
  634.  
  635.         MAXIMUM COMPRESSED IPX PACKET
  636.  
  637.         +--------+--------+---------+---------+--------+---------
  638.         | Flags  |  Slot  |Checksum | Length  |NCP Task| DATA ...
  639.         |  0xF0  | Number |2 octets |3 octets | Number |
  640.         +--------+--------+---------+---------+--------+---------
  641.  
  642.         MAXIMUM COMPRESSED NCP/IPX PACKET
  643.  
  644. Regular Packet
  645.  
  646.    The Regular packet type designates an IPX packet for which no
  647.    compression is desired.  This type of packet is sent when a packet
  648.    cannot be compressed, or a decision is made not to compress it.
  649.  
  650.           7   6   5   4   3   2   1   0
  651.         +---+---+---+---+---+---+---+---+
  652.         | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
  653.         +---+---+---+---+---+---+---+---+
  654.           ^   ^   ^   ^   ^   ^   ^   ^
  655.           |   |   |   |   |   |   |   |
  656.           |   |   |   |   |___|___|___|___ Packet Type
  657.           |   |   |   |                    1    Regular
  658.           |   |   |   |
  659.           |__ |__ |__ |___________________ Reserved (must be zero)
  660.  
  661.    The Regular packet is rarely sent.  Usually, the Regular packet is
  662.    sent when there is not enough memory for the overhead of a new
  663.    compression slot.  Also, this type is included for future unforeseen
  664.    changes to the IPX protocol which defeat the effectiveness of
  665.    compression.
  666.  
  667.       Implementation Note:
  668.  
  669.          The Regular Packet can be used for packets that are sporadic,
  670.          which are not worth setting-up a compression slot.  This may be
  671.  
  672.  
  673.  
  674. Mathur & Lewis                                                 [Page 12]
  675.  
  676. RFC 1553                         CIPX                      December 1993
  677.  
  678.  
  679.          hard to determine for specific protocols.  Various methods such
  680.          as hold-down and least-recently-used timers are currently being
  681.          used.
  682.  
  683.       On receipt, the 1 octet header is simply removed and the packet
  684.       passed up to IPX.
  685.  
  686.       The entire IPX packet follows the single Flags octet.  Note for a
  687.       Regular Packet (not compressed or uncompressed), the slot number
  688.       field is not included.
  689.  
  690. Confirmed Initial Packet
  691.  
  692.    The Confirmed Initial packet type is used by the compressor to inform
  693.    the decompressor of the original packet header which will be used for
  694.    subsequent compression, and to request Confirmation.  The high order
  695.    4 bits are reserved for expansion to support additional protocols.
  696.  
  697.           7   6   5   4   3   2   1   0
  698.         +---+---+---+---+---+---+---+---+
  699.         | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
  700.         +---+---+---+---+---+---+---+---+
  701.           ^   ^   ^   ^   ^   ^   ^   ^
  702.           |   |   |   |   |   |   |   |
  703.           |   |   |   |   |___|___|___|___ Packet Type
  704.           |   |   |   |                    3     Confirmed Initial
  705.           |   |   |   |
  706.           |__ |__ |__ |___________________ 0     IPX Protocol
  707.                                            1-15  Reserved
  708.  
  709.    This type of packet is sent to inform the receiver to associate the
  710.    IPX packet header with a slot number.  This packet is sent each time
  711.    a different header format is sent for a given slot, or when the
  712.    sender has not received a Confirmation Packet from the receiver.
  713.  
  714.    The Flags octet lower 4 bits indicate the Confirmed Initial CIPX
  715.    packet type.  The high order 4 bits are reserved for expansion to
  716.    support additional protocols.  The Flags octet is always followed by
  717.    the Slot Number and an ID field.  The ID field is one octet in
  718.    length.
  719.  
  720.    For each slot, the ID will increment with every new header sent.
  721.    Different slots may have the same ID.  The combination of slot and ID
  722.    uniquely identify a header.  In practice, the ID octet can be any
  723.    number which is unique for a "reasonably long period" of time.  A
  724.    reasonably long period is a function of transmission speed, round
  725.    trip delays, and network load.  There must be very little chance of
  726.    duplicate slot and ID combinations within this period.  Otherwise,
  727.  
  728.  
  729.  
  730. Mathur & Lewis                                                 [Page 13]
  731.  
  732. RFC 1553                         CIPX                      December 1993
  733.  
  734.  
  735.    there is ambiguity as to which header is being identified.
  736.  
  737.       Implementation Note:
  738.  
  739.          There is no requirement to hold or resend the Confirmed Initial
  740.          packet until confirmation.  When a new packet with the same IPX
  741.          header is to be sent, another Confirmed Initial packet should
  742.          be sent using the same slot, the same ID, and the new packet
  743.          data.
  744.  
  745.          When a new packet with a different IPX header is to be sent, it
  746.          may be sent using a slot which has not received confirmation.
  747.          A Confirmed Initial packet is sent with the same slot, an
  748.          incremented ID, and the new packet data.  Assuming a least-
  749.          recently-used policy for selecting a slot for a new IPX header,
  750.          this provides the ability to reuse slots when a Confirmed
  751.          Initial packet has been sent but not confirmed.
  752.  
  753.               +---------+---------+---------+-/       /-+----------
  754.               |  Flags  |   Slot  |   ID    |    IPX    |  DATA ...
  755.               |   0x03  |  Number |         |   Header  |
  756.               +---------+---------+---------+-/       /-+----------
  757.  
  758. CONFIRMED INITIAL PACKET
  759.  
  760.    Note that a Confirmed Initial header is followed by a complete IPX
  761.    packet.
  762.  
  763. Confirm Packet
  764.  
  765.    The Confirm packet type is used by the decompressor to tell the
  766.    compressor that it has received the Confirmed Initial packet.
  767.  
  768.    When the compressor receives this, it can start sending Compressed
  769.    frames.
  770.  
  771.           7   6   5   4   3   2   1   0
  772.         +---+---+---+---+---+---+---+---+
  773.         | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
  774.         +---+---+---+---+---+---+---+---+
  775.           ^   ^   ^   ^   ^   ^   ^   ^
  776.           |   |   |   |   |   |   |   |
  777.           |   |   |   |   |___|___|___|___ Packet Type
  778.           |   |   |   |                    5    Confirm
  779.           |   |   |   |
  780.           |__ |__ |__ |___________________ Reserved (must be zero)
  781.  
  782.    A Confirm Packet is exactly 3 octets in length.  It consists of the
  783.  
  784.  
  785.  
  786. Mathur & Lewis                                                 [Page 14]
  787.  
  788. RFC 1553                         CIPX                      December 1993
  789.  
  790.  
  791.    Flags, Slot Number and ID fields.  The Slot Number field contains the
  792.    number of the slot which is being acknowledged.  The ID field
  793.    contains the ID of the Confirmed Initial Packet which is being
  794.    acknowledged.
  795.  
  796.         +---------+---------+----------+
  797.         |  Flags  |   Slot  |    ID    |
  798.         |   0x05  |  Number |          |
  799.         +---------+---------+----------+
  800.  
  801. CONFIRM PACKET
  802.  
  803. Unconfirmed Initial Packet
  804.  
  805.    The Unconfirmed Initial packet type is used by the compressor to
  806.    inform the decompressor of the original packet header which will be
  807.    used for subsequent compression while not requesting confirmation.
  808.  
  809.    After sending an Unconfirmed Initial packet, the compressor may
  810.    immediately send Compressed packets without confirmation.
  811.  
  812.           7   6   5   4   3   2   1   0
  813.         +---+---+---+---+---+---+---+---+
  814.         | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 |
  815.         +---+---+---+---+---+---+---+---+
  816.           ^   ^   ^   ^   ^   ^   ^   ^
  817.           |   |   |   |   |   |   |   |
  818.           |   |   |   |   |___|___|___|___ Packet Type
  819.           |   |   |   |                    7     Unconfirmed Initial
  820.           |   |   |   |
  821.           |__ |__ |__ |___________________ 0     NCP Protocol
  822.                                            1-15  Reserved
  823.  
  824.    This type of packet is sent to inform the receiver to associate the
  825.    IPX packet header with a slot number.  This packet is sent each time
  826.    a different header format is sent for a given slot.
  827.  
  828.    The Flags octet lower 4 bits indicate the Unconfirmed Initial CIPX
  829.    packet type.  The high order 4 bits are reserved for expansion to
  830.    support additional protocols.  The Flags octet is always followed by
  831.    the Slot Number.
  832.  
  833.         +---------+---------+-/        /-+-/       /-+---------
  834.         |  Flags  |   Slot  |    IPX     |    NCP    | NCP
  835.         |   0x07  |  Number |   Header   |   Header  | DATA ...
  836.         +---------+---------+-/        /-+-/       /-+---------
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Mathur & Lewis                                                 [Page 15]
  843.  
  844. RFC 1553                         CIPX                      December 1993
  845.  
  846.  
  847. UNCONFIRMED INITIAL PACKET
  848.  
  849.  
  850.    Note that an Unconfirmed Initial header is followed by a complete IPX
  851.    packet.
  852.  
  853. Reject Packet
  854.  
  855.    The Reject packet type is used by the decompressor to tell the
  856.    compressor that it has received a CIPX packet with a header which it
  857.    does not support.  This is provided to regulate future extensions to
  858.    CIPX.
  859.  
  860.           7   6   5   4   3   2   1   0
  861.         +---+---+---+---+---+---+---+---+
  862.         | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
  863.         +---+---+---+---+---+---+---+---+
  864.           ^   ^   ^   ^   ^   ^   ^   ^
  865.           |   |   |   |   |   |   |   |
  866.           |   |   |   |   |___|___|___|___ Packet Type
  867.           |   |   |   |                    9    Reject
  868.           |   |   |   |
  869.           |__ |__ |__ |___________________ Reserved (must be zero)
  870.  
  871.    A Reject Packet is exactly 3 octets in length.  It consists of the
  872.    Flags, Slot Number and Rejected Flags fields.
  873.  
  874.    The Slot Number field contains the number of the slot of the packet
  875.    which is being rejected.  Since the actual packet type may be unknown
  876.    or misunderstood, this field actually contains the second octet of
  877.    the rejected packet.  In the normal case of a known CIPX packet type,
  878.    this will be the slot number of an initial packet.
  879.  
  880.    The Rejected Flags field contains the first octet of the packet being
  881.    rejected.  The packet type field is left untouched.  Any flags which
  882.    are correctly recognized should be cleared.  The remaining flags
  883.    indicate specific features that are being rejected.  This information
  884.    should be sufficient for implementations to adjust the use of certain
  885.    packet types or dependent flags.
  886.  
  887.       Implementation Note:
  888.  
  889.          The Flags value of 0xFF is not a valid CIPX packet type.
  890.          Hence, such a packet type should be recognized as a standard
  891.          IPX header and forwarded without CIPX processing to the
  892.          appropriate routines.  Under no circumstances should a Flags
  893.          value of 0xFF be rejected in a Reject Packet.
  894.  
  895.  
  896.  
  897.  
  898. Mathur & Lewis                                                 [Page 16]
  899.  
  900. RFC 1553                         CIPX                      December 1993
  901.  
  902.  
  903.               +---------+---------+----------+
  904.               |  Flags  |   Slot  | Rejected |
  905.               |   0x09  |  Number |  Flags   |
  906.               +---------+---------+----------+
  907.  
  908.               REJECT PACKET
  909.  
  910. Compression Negotiation over PPP Links
  911.  
  912.    For PPP links [5], the use of header compression can be negotiated by
  913.    IPXCP [6].  By default, no compression is enabled.
  914.  
  915.    The IPX-Compression-Protocol Configuration Option is used to indicate
  916.    the ability to receive compressed packets.  Each end of the link must
  917.    separately request this option if bi-directional compression is
  918.    desired.
  919.  
  920.    The PPP Protocol field is set to the same value as the usual IPX
  921.    packets, and all IPX packets sent over the link MUST conform to the
  922.    compressed format.
  923.  
  924.    A summary of the IPX-Compression-Protocol Configuration Option format
  925.    to negotiate Telebit IPX header compression (CIPX) is shown below.
  926.    The fields are transmitted from left to right.
  927.  
  928.          0                   1                   2                   3
  929.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  930.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  931.         |     Type      |    Length     |    IPX-Compression-Protocol   |
  932.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  933.         |  Max-Slot-Id  |    Options    |
  934.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  935.  
  936.        Type
  937.  
  938.            3
  939.  
  940.        Length
  941.  
  942.            6
  943.  
  944.        IPX-Compression-Protocol
  945.  
  946.            0002 (hex) for Telebit Compressed IPX headers (CIPX).
  947.  
  948.         Max-Slot-Id
  949.  
  950.            The Max-Slot-Id field is one octet and indicates the maximum
  951.  
  952.  
  953.  
  954. Mathur & Lewis                                                 [Page 17]
  955.  
  956. RFC 1553                         CIPX                      December 1993
  957.  
  958.  
  959.            slot identifier.  This is one less than the actual number of
  960.            slots; the slot identifier has values from zero to Max-Slot-
  961.            Id.
  962.  
  963. Options
  964.  
  965.    The Options field is one octet, and is comprised of the "logical or"
  966.    of the following values:
  967.  
  968.       0  No options.
  969.  
  970.       1  The slot identifer may be compressed.
  971.  
  972.          The slot identifier must not be compressed if there is no
  973.          ability for the PPP link level to indicate an error in
  974.          reception to the decompression module.  Synchronization after
  975.          errors depends on receiving a packet with the slot identifier.
  976.  
  977.       2  Redefine Compressed Packet type bits 1-3.
  978.  
  979.          It was noted earlier that packet types have been chosen such
  980.          that only the Compressed Packet type is an even number value
  981.          with the lowest order bit of zero.  All other packet types are
  982.          odd values with a lowest order bit of one.  The reason for this
  983.          assignment was to make it possible to determine the Compressed
  984.          Packet type by examining only one bit.  This make it possible
  985.          to use all the other 7 bits to indicate status in the
  986.          Compressed Packet.  The 7 bits are composed of the upper 4 bits
  987.          which are permanently defined to indicate packet dependent
  988.          flags, plus bits 1-3 which are otherwise part of the Packet
  989.          Type.  The upper 4 bits are defined above.  The redefinition of
  990.          bits 1-3 of the Compressed Packet type is left for future
  991.          expansion.
  992.  
  993.                7   6   5   4   3   2   1   0
  994.              +---+---+---+---+---+---+---+---+
  995.              |   |   |   |   |   |   |   | 0 |
  996.              +---+---+---+---+---+---+---+---+
  997.                ^   ^   ^   ^   ^   ^   ^   ^
  998.                |   |   |   |   |   |   |   |___ Packet Type
  999.                |   |   |   |   |   |   |        0    Compressed Packet
  1000.                |   |   |   |   |   |   |
  1001.                |   |   |   |   |___|___|_______ Redefined bits
  1002.                |   |   |   |
  1003.                |___|___|___|___________________ Compressed Packet flags
  1004.  
  1005.          By default, this feature in not enabled and this flag is
  1006.          set to zero.  When this flag is set to one, it indicates
  1007.  
  1008.  
  1009.  
  1010. Mathur & Lewis                                                 [Page 18]
  1011.  
  1012. RFC 1553                         CIPX                      December 1993
  1013.  
  1014.  
  1015.          the desire to use this feature.
  1016.  
  1017. Compression Negotiation over IPXWAN Links
  1018.  
  1019.    "IPXWAN" is the protocol Novell uses to exchange necessary router
  1020.    to router information prior to exchanging standard IPX routing
  1021.    information and traffic over WAN datalinks [7].  To negotiate the
  1022.    Telebit compression option, we use Novell's allocated option number
  1023.    for CIPX (00) in the IPXWAN timer request/response packet.
  1024.  
  1025.    The Timer Request packet contains the following Telebit compression
  1026.    option:
  1027.  
  1028.      WOption Number       80        - Define compression type
  1029.      WAccept Option       01        - 0=No, 1=Yes, 3=N/A
  1030.      WOption Data Len     00 03     - Length of option
  1031.      WOption Data         00        - Telebit's compression (CIPX)
  1032.      WOption Data         XX        - Compression options
  1033.      WOption Data         NN        - Compression slots
  1034.  
  1035.    Where the WOption Data fields are:
  1036.  
  1037.      00   Telebit's compression option described in this
  1038.           document (CIPX).
  1039.  
  1040.      XX   Compression options as defined below:
  1041.  
  1042.              0x01   Compress slot ID when possible
  1043.              0x02   Redefine Compressed Packet type bits 1-3.
  1044.  
  1045.      NN   The requested # of compression slots.
  1046.  
  1047.      Accept Option (for compression type) must be set to YES if the
  1048.      option is supported and NO if the option is not supported.  A Timer
  1049.      Response must respond with only one header compression type set to
  1050.      YES.
  1051.  
  1052.      The Timer Response packet that accepts the option will look like
  1053.      this:
  1054.  
  1055.      WOption Number       80        - Define compression type
  1056.      WAccept Option       01        - 0=No, 1=Yes, 3=N/A
  1057.      WOption Data Len     00 03     - Length of option
  1058.      WOption Data         00        - Telebit's compression (CIPX)
  1059.      WOption Data         XX        - Compression options
  1060.      WOption Data         NN        - Compression slots
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Mathur & Lewis                                                 [Page 19]
  1067.  
  1068. RFC 1553                         CIPX                      December 1993
  1069.  
  1070.  
  1071.    Where the WOption Data fields are:
  1072.  
  1073.      00   Telebit's compression option described in this
  1074.           document (CIPX).
  1075.  
  1076.      XX   Compression options as defined below:
  1077.  
  1078.              0x01   Compress slot ID when possible
  1079.              0x02   Redefine Compressed Packet type bits 1-3.
  1080.  
  1081.      NN   The negotiated # of slots (The lower of each side's
  1082.           requested number of slots)
  1083.  
  1084.    IPX packets (except of course IPXWAN packets) are not sent over the
  1085.    link until the IPXWAN negotiations are completed.  Once IPXWAN
  1086.    negotiations are completed, regular IPX packets can be sent over the
  1087.    link.
  1088.  
  1089.    If both ends of the link agree on the compression options, then the
  1090.    IPX packets are sent using the specified options.  If either end of
  1091.    the link does not accept a compression option, then this compression
  1092.    option will not be used.  Compression will be done using any
  1093.    remaining options.  Options, by definition, are not required.
  1094.    Implementations MUST support CIPX without any options.
  1095.  
  1096.    It is the responsibility of the router sending the IPXWAN Timer
  1097.    Response to inform the other router of the options that will be used.
  1098.    The Timer Response MUST contain a subset of the options received in a
  1099.    Timer Request.
  1100.  
  1101.    To be clear, IPXWAN is used to set up a symmetrical compression link.
  1102.    Compression is configured identically in both directions.  Each end
  1103.    will use the same number of slots and same compression options.  It
  1104.    is illegal for link ends to use different number of slots or
  1105.    different options.
  1106.  
  1107. IPX Compression Performance
  1108.  
  1109.    The performance of this algorithm will depend on the number of active
  1110.    connections and the number of slots negotiated.  If the number of
  1111.    slots is greater than the number of connections, the hit rate should
  1112.    be very high giving a very high compression ratio.  The performance
  1113.    also depends on the average size of the IPX packets.  If the average
  1114.    size of packets is small, then compression will result in a more
  1115.    noticeable performance improvement.
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Mathur & Lewis                                                 [Page 20]
  1123.  
  1124. RFC 1553                         CIPX                      December 1993
  1125.  
  1126.  
  1127.                             avg_data_len + uncomp_header_len
  1128.         Compression ratio = ----------------------------------
  1129.                             avg_data_len + avg_comp_header_len
  1130.  
  1131.    Where 'avg_data_len' is the average length of data in the IPX packet,
  1132.    and 'uncomp_head_len' is the uncompressed header length which is
  1133.    fixed at 30 octets.  Where 'avg_comp_header_len' is the average
  1134.    length of the compressed IPX header.  The length of the minimum
  1135.    compressed IPX header is 1 octet.  The length of the maximum
  1136.    compressed NCP/IPX header is 8 octets (including the NCP task
  1137.    number), but since no implementation yet sends packets with a length
  1138.    greater than 16K, 7 octets is the commonly encountered maximum.
  1139.    Perhaps a reasonable 'avg_comp_header_len' is 2, assuming the
  1140.    inclusion of the flag and slot number octets.
  1141.  
  1142.    The maximum length of the data in an IPX packet is 546 octets (576
  1143.    octets - 30 octet IPX header), although newer implementations may
  1144.    send packets of up to 4096 octets.  The minimum length of the data in
  1145.    an IPX packet is 1 octet.  Within the normal distribution of small
  1146.    NCP packets, perhaps a reasonable 'avg_data_len' is 26 octets.
  1147.  
  1148.                                  546 + 30
  1149.         Minimal Compression    = -------- =  1.04
  1150.                                  546 + 6
  1151.  
  1152.                                  1 + 30
  1153.         Maximal Compression    = ------   = 15.50
  1154.                                  1 + 1
  1155.  
  1156.                                  26 + 30
  1157.         Likely Compression     = -------  =  2.00
  1158.                                  26 + 2
  1159.  
  1160.  
  1161. Security Considerations
  1162.  
  1163.    IPX provides some security features, which are fully applicable to
  1164.    CIPX.  CIPX does not significantly alter the basic security of IPX.
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Mathur & Lewis                                                 [Page 21]
  1179.  
  1180. RFC 1553                         CIPX                      December 1993
  1181.  
  1182.  
  1183. References
  1184.  
  1185.    [1] Novell Inc., "IPX Router Specification", September 1992, Part
  1186.        Number: 107-000029-001
  1187.  
  1188.    [2] Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed Serial
  1189.        Links", RFC 1144, February 1990
  1190.  
  1191.    [3] CCITT Recommendation V.42bis Error Correcting Procedures for DCEs
  1192.        using Error Correction Procedures
  1193.  
  1194.    [4] ISO 7776, Information Processing Systems - Data Communication -
  1195.        High Level Data Link Control Procedures - Description of the X.25
  1196.        LAPB-Compatible DTE Data Link Procedures
  1197.  
  1198.    [5] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1548,
  1199.        December 1993
  1200.  
  1201.    [6] Simpson, W. A., "The PPP Internet Packet Exchange Control
  1202.        Protocol (IPXCP)", RFC 1552, December 1993
  1203.  
  1204.    [7] Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]",
  1205.        RFC 1551, December 1993
  1206.  
  1207. Acknowledgements
  1208.  
  1209.    This compression algorithm incorporates many ideas from the Van
  1210.    Jacobson TCP/IP header compression algorithm.
  1211.  
  1212.    Michael Allen from Novell provided a lot of valuable feedback in the
  1213.    design of this algorithm.  David Piscitello from Bellcore and Marty
  1214.    Del Vecchio at Shiva Corp.  made several good suggestions.  Bill
  1215.    Simpson was very helpful in driving PPP, and specifically IPXCP, on
  1216.    the standards course.
  1217.  
  1218. Chair's Address
  1219.       Fred Baker
  1220.       Advanced Computer Communications
  1221.       315 Bollay Drive
  1222.       Santa Barbara, California 93117
  1223.  
  1224.       EMail: fbaker@acc.com
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Mathur & Lewis                                                 [Page 22]
  1235.  
  1236. RFC 1553                         CIPX                      December 1993
  1237.  
  1238.  
  1239. Authors' Addresses
  1240.  
  1241.       Saroop Mathur
  1242.       Telebit Corp.
  1243.       1315 Chesapeake Terrace
  1244.       Sunnyvale, CA 94089-1100
  1245.  
  1246.       EMail: mathur@telebit.com
  1247.  
  1248.       Mark S. Lewis
  1249.       Telebit Corp.
  1250.       1315 Chesapeake Terrace
  1251.       Sunnyvale, CA 94089-1100
  1252.  
  1253.       EMail: Mark.S.Lewis@telebit.com
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Mathur & Lewis                                                 [Page 23]
  1291.  
  1292.